1. The Field of the Invention
The present invention relates to testing computer systems and computer related devices for desired functionality. More specifically, the present invention relates to mechanisms for testing computer systems and computer related devices for compliance with Universal Plug and Play (“UPnP™”) protocols.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices. can transfer electronic data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, controlling home electronics, web browsing) include electronic communication between a number of computer systems and/or other electronic devices via wired and/or wireless computer networks.
In particular, a computer system may communicate with networked peripheral devices, such as, for example, printers, scanners and network gateways, to perform an action, such as, for example, printing or scanning a document or accessing a network. Networking peripheral devices is advantageous as it allows a number of computer systems to the share the peripheral devices. For example, any computer systems connected to a common network with a printer may be able to utilize the printer to print documents.
However, to utilize a networked peripheral device, a computer system has typically been required to have an appropriate device driver for the peripheral device. A device driver essentially converts computer system commands into compatible instructions that cause a corresponding peripheral device to perform an action. For example, a device driver for a networked printer could convert computer system commands into compatible instructions for causing the networked printer to print a document. Without an appropriate device driver, a computer system may not be able to cause a peripheral device to perform any actions.
The requirement of having an appropriate device driver can be particularly problematic when a computer system is moved between different networks. For example, a computer system that is typically connected to an office LAN (Local Area Network) may from time to time also connect to other networks (e.g., wireless networks) in various hotels or airports when a computer system user is traveling. However, there may be no way for the user to determine before traveling what peripherals are connected to the other networks. Thus, upon connecting to another network, the computer system may be prevented from compatibly communicating with connected peripheral devices due to the computer system not including the appropriate device drivers.
Further, most device drivers are designed to function with a single or limited number of peripheral devices. Since there are a large number of different peripheral devices that may be connected to a network, it would be difficult and time consuming to load device drivers for each and every possible peripheral device. Unused devices drivers also unnecessarily consume computer system resources (e.g., disk space and potentially system memory), preventing other computer system processes from utilizing the computer system resources.
Accordingly, at least one mechanism for reducing the need for different device drivers has been developed. Universal Plug and Play (which may be referred to as “UPnP™”) uses common protocols, instead of device drivers, to facilitate communication between a computer system and a peripheral device. UPnP™ significantly reduces the configuration needed to enable UPnP™ compatible devices to communicate. Through the use of common protocols, peripheral devices (and computer systems) can dynamically join a network, obtain a network address, convey device capabilities and discovery the capabilities of other devices.
However, UPnP™ is, for the most part, only useful if devices and computer systems support the same set of common protocols. If devices and computer systems support different common protocols or lack support for common protocols, interoperation between some devices and/or some computer systems can be difficult or even impossible. Accordingly, testing mechanisms have been developed to test devices for compliance with UPnP™ protocols.
One testing mechanism utilizes eXtensible Markup Language (“XML”) instructions to simulate UPnP™ Simple Object Access Protocol (“SOAP”) commands generated at a computer system or peripheral device. A device and a computer system are connected to a common network hub. The network hub is isolated from other devices and computer systems that may interfere with testing. A tester executes a UPnP™ test tool executable (e.g., a “.exe” file) at the computer system causing a user-interface to load. The tester uses the user-interface to select one or more categories of tests (e.g., from among addressing tests, description tests, discovery tests, eventing tests, etc.) that are embedded in the test tool. The tester may also create a log file (e.g., a “.TXT” file or other text file) used to store test results.
The tester selects an appropriate control (e.g., a “Start” button) to cause the device to be tested in the selected categories. Testing a device in a specific category can include the computer system sending Simple Object Access Protocol (“SOAP”) packets to the device to simulate UPnP™ commands. For example, testing control syntax of a printer device could include sending a “cancel print ID” action to the printer device. Response messages returned form the printer device (e.g., “print ID cancelled”) can be stored in the log file.
When a device provides appropriate data in response to tests in a number of different test categories, the device can be viewed as complying with a UPnP™ device architecture (e.g., version 1 or version 2). A compliant device can be certified and tagged with a logo indicating that the device supports UPnP™. A central authority can determine if test results sufficiently indicate compliance with the UPnP™ device architecture. Accordingly, entities desiring to become certified can submit log files to the central authority for review. When a log file indicates that a device has responded with the appropriate data in response to SOAP instructions simulating UPnP™ commands, the central authority can certify that the device supports UPnP™. The testing and certification processes increase the likelihood of certified devices being able to appropriately interoperate using UPnP™.
Unfortunately, conventional UPnP™ compliance testing suffers from a number of deficiencies. One deficiency is related to using XML to define test cases. XML does not natively include support for performing more programmatic functions (e.g., looping, conditional statements, responding to and/or storing returned data values, etc). Thus, when using XML it may be difficult, or even impossible, to implement some tests. For example, it would difficult to create an XML based test that sends find requests to a device until the device times out. Since XML has no mechanism for storing variable data value there would be no way for the XML based test to stop sending find requests in response to the timeout message.
Another deficiency relates to isolating a computer system and device from other computer systems and devices. Conventionally, testing mechanisms lack the ability to address specific devices. Thus, there is no way to select a specific device from a number of devices that are connected to a common network. Further, when testing a device for UPnP™ compliance, other devices may interfere with the testing (e.g., sending event messages, responding to simulated queries, etc.) causing the tests to inappropriately fail. Thus during UPnP™ compliance testing, a device and computer system are typically isolated from other devices and computer systems. Accordingly, testing large numbers of devices can be time consuming as each device must individual be connected to the isolated network, tested, and then removed from the isolated network.
Another deficiency relates to the data format of log files. Since log files are typically stored in text format, the logs can be easily manipulated. For example, a tester (or other individual) could intentionally alter a log file to change failing test results to passing test results. There is also some chance that a tester (or other individual) could inadvertently alter passing test results to failing test results when reviewing a log file. However, upon receiving a log file, the certification authority has limited, if any, mechanism for determining if a received log file was altered. Thus, the certification authority may incorrectly certify or deny certification for a tested device. Accordingly, what would be advantageous are mechanisms for enhancing Universal Plug and Play testing.